Brief Full Advanced Search Search Tips
|  |  | To access the contents, click the chapter and section titles. Visual Basic 6 Programming Blue Book: The Most Complete, Hands-On Resource for Writing Programs with Microsoft Visual Basic 6! (Publisher: The Coriolis Group) Author(s): Peter G. Aitken ISBN: 1576102815 Publication Date: 08/01/98 Search this book:
Previous | Table of Contents | Next
#### Event Procedures Earlier in this chapter, I mentioned that Visual Basic brought two groundbreaking innovations to Windows programming. The first one was visual interface design. Now we’ll meet the second one: event detection. Well, not event detection itself; that’s nothing new. The real innovation is the ease with which a programmer can make his or her program respond to events, and this is all accomplished with event procedures. An event procedure is a block of Basic code associated with an event. When the event is detected, the code in the procedure is automatically executed. Creating an event procedure in Visual Basic is a simple two-step process: 1. Select the object (Text Box, Command Button, etc.) that will respond to the event. 2. Choose the desired event from a list of events that the selected object can detect. It’s really that simple. Carrying out these steps creates the skeleton of an event procedure that has this general form:
    Sub ObjName_Event()

    End Sub
The name of the event procedure identifies both the visual object and the event. ObjName is the name of the object (its Name property), and Event is the name of the event. For example, the event procedure to detect a mouse click on a Command Button named ExitButton would be ExitButton_Click. This procedure is executed when the program runs and the user clicks on the button. Nothing more is involved in getting the program to respond to events. Of course, you must still write the code that will be executed within the event procedure. The skeleton procedure above is empty and does nothing when it executes. We’ll be spending a lot of time learning Basic code, so you’ll soon be able to write event procedures that perform useful tasks. Actually, event procedure code usually does not perform the task itself, but rather calls code that is located elsewhere—outside the event procedure—to do the work. The reasons for this will be explained in a later chapter. In any event (pardon the pun), the result is the same: The program responds to user input. Visual Basic puts the entire range of user events at your fingertips. When creating a program, you need only decide which events the program should respond to, and what the response will be. If you do not create an event procedure for a particular event, the program will ignore that event. ### The Software Component Mindset Sure, software components sound like a good idea, and anyone can see the advantages of using them. But to derive the maximum benefit from components, you will have to develop a specific way of thinking when creating Visual Basic programs. This attitude is something I call the software component mindset, and it goes beyond thinking, “Oh yeah, maybe I can use a software component here.” Rather, it’s the habit of starting at the very beginning, when the structure of your Visual Basic program begins to take shape in your mind, with the goal of using as many software components as possible. In simple terms, invent as few wheels as possible. Not only do you want to maximize the use of existing components in your program, you also want to remain aware of creating your own components. Almost all of the programs you write will include certain tasks for which you will not be able to use an existing component. You’ll have to write them yourself. With a bit of planning, you can create components for these functions, and these components will be available to you in the future. After a while, you’ll find yourself with a small library of software components that perform the functions you need most often in your programs. As for custom controls, you can’t use them if you don’t know what’s available. Dozens of publishers and private programmers are continually devising new custom controls, expanding the already wide variety available. To keep aware of what’s out there, you may want to subscribe to a Visual Basic programming magazine, place yourself on some manufacturers’ mailing lists, attend Visual Basic trade shows, browse Visual Basic newsgroups on the Internet, and frequent the Visual Basic programming forums on CompuServe, America Online, and other online services. The cost of certain commercial custom controls may seem high at first, but they all turn out to be relatively inexpensive when you figure in the time and aggravation you’ll save. This is particularly true if you are writing Visual Basic programs for paying clients, who can be mighty impressed when you deliver a robust, powerful program ahead of schedule. ### The Role Of Code What’s the role of Basic code in Visual Basic? Isn’t programming supposed to require writing lots of code? So far, I’ve been talking about everything except code—objects, properties, components, and whatnot. Where’s the code? Don’t worry, you’ll be writing plenty of code for your Visual Basic programs. While some programs require less code than others, some behind-the-scenes code is always needed to tie everything together and perform the real work of the program. If you want to perform mathematical calculations, read data from disk, display on-screen graphics or text, or send data over a modem, you’ll have to write the code for it. If you want to display a form, change an object’s properties, or respond to an event, you’ll have to write code. If you want your program to recover gracefully from errors, you’ll have to write code. Code ties all the program’s objects together, linking them to each other, to the user, and to the outside world. Code plays a mighty big role in Visual Basic. ### What’s Next? If you’ve managed to slog though this entire chapter, you are probably raring to take Visual Basic for a spin. We’ll get to that in the next chapter. If you’ll bear with me for another moment, I’d like to finish with a few suggestions and reminders about Visual Basic programming: • Plan ahead—As with all types of programming, creating a Visual Basic program will always go more smoothly if you spend some time planning. Think about what you need to do in the context of Visual Basic’s available tools. This sort of planning is more difficult when you’re just starting out with Visual Basic, because you are unfamiliar with its capabilities. But as you gain expertise, planning should become a top priority. • Think like a user—Design your program from the user’s perspective. Don’t base the design on what’s easy for you to program. What data will the user want to see? How will he or she want it displayed? What tasks (and in what order) will the user need to perform? Many technically talented programmers have seen their work collect dust on users’ shelves because they neglected to follow this advice. • Think components—Once you have some idea of what your program will do, start looking for existing software components that can handle parts of the job. When you’re doing it yourself, try to encapsulate your interface and code elements in self-contained components that you can reuse in future projects. • Learn by doing—Programming is like surgery (except for the pay, of course): You can read every book on the market, but you’ll never learn how to do it until you actually do it. That’s the approach I take in this book, and so should you. Yes, you should definitely read the rest of this book, but you should also spend as much time as possible working with Visual Basic. You’ll be pleasantly surprised at how quickly your programming skills improve. • Learn from other Visual Basic programs—Take time to examine other Visual Basic programs. You never know when you might trip over an idea or technique that you can use in your own work. Sources for Visual Basic programs include the samples provided with the Visual Basic package, Visual Basic programming forums provided by online services, and books and magazines. And now, friends, into the fray.
Previous | Table of Contents | Next

| Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.